home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / p_man / cat5 / timers.z / timers
Encoding:
Text File  |  2002-10-03  |  8.6 KB  |  199 lines
  1.  
  2.  
  3.  
  4. ttttiiiimmmmeeeerrrrssss((((5555))))                                                            ttttiiiimmmmeeeerrrrssss((((5555))))
  5.  
  6.  
  7.  
  8. NNNNAAAAMMMMEEEE
  9.      _tttt_iiii_mmmm_eeee_rrrr_ssss - timers and process time accounting information
  10.  
  11. SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
  12.      _####_iiii_nnnn_cccc_llll_uuuu_dddd_eeee _<<<<_ssss_yyyy_ssss_////_tttt_iiii_mmmm_eeee_...._hhhh_>>>>
  13.  
  14. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  15.      The timing facilities under IRIX consist of interval timers, event
  16.      timing, process execution time accounting, and time of day reporting.
  17.  
  18.      _I_n_t_e_r_v_a_l _t_i_m_e_r_s consist of POSIX timers (see timer_create (3c)), and
  19.      itimers that were introduced in BSD4.2 (see getitimer(2)).  Use of the
  20.      POSIX timers is strongly recommended for new applications.  The IRIX-
  21.      unique BSD4.2 itimers are supported only to provide compatibility for
  22.      older applications.
  23.  
  24.      On Silicon Graphics machines there are two independent timers per
  25.      processor.  The first interrupts the processor at a regular interval of
  26.      10 milliseconds and is used for scheduling and statistics gathering.  The
  27.      second interrupts the processor at _f_a_s_t_h_z frequency and is used to
  28.      support the high resolution POSIX and itimer capabilities.  On
  29.      multiprocessor machines, one processor is used to maintain system time
  30.      and is labeled the _c_l_o_c_k processor.  One additional processor is required
  31.      to service the POSIX timer and itimer requests and is labeled the _f_a_s_t
  32.      _c_l_o_c_k processor.  The mpadmin(1) command can be used to bind the clock
  33.      and fast clock to a particular physical processor.
  34.  
  35.      A realtime process (one with priority between NDPHIMAX and NDPHIMIN) may
  36.      make POSIX timer requests, or itimer requests with a resolution greater
  37.      than 10 milliseconds when using the realtime timer.  The limit on the
  38.      resolution depends on the underlying hardware and can be dynamically
  39.      determined by examining the variable _f_a_s_t_h_z using systune(1M) or by
  40.      opening /dev/kmem and reading _f_a_s_t_h_z as a 4 byte word.  The _f_a_s_t_h_z
  41.      variable can also be modified using systune(1M).
  42.  
  43.      On the Indigo, Indy, Indigo, O2, and Octane products, acceptable values
  44.      for _f_a_s_t_h_z are 500, 1000, and 2500 Hz.  If the requested value is not one
  45.      of these values, then the default value of 1000 Hz is used.  On the
  46.      Challenge Series, the resolution of the hardware timer is 21 nanoseconds
  47.      and therefore any value smaller than 47MHz is possible.  For realistic
  48.      results, no _f_a_s_t_h_z value larger than 2000 Hz should be specified because
  49.      the kernel cannot reliably deliver itimer signals at a greater rate.
  50.  
  51.      On Onyx2, Onyx3, and Origin Systems, _f_a_s_t_h_z has a value of 1250 Hz which
  52.      gives a resolution of 0.8 microseconds.  For processes running with
  53.      either the FIFO or RR scheduling policies, both POSIX timers with
  54.      CLOCK_SGI_FAST, and itimers with ITIMER_REAL have a resolution of 0.8
  55.      microseconds.  This does not necessarily mean that timer interrupts can
  56.      be received at that frequency, the timers simply have that resolution.
  57.      It is not possible to achieve better than 10 millisecond timer accuracy
  58.      when running without either a FIFO or RR scheduling policy.  To take low
  59.      latency timestamps with maximum resolution on Onyx2, Onyx3 and Origin
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. ttttiiiimmmmeeeerrrrssss((((5555))))                                                            ttttiiiimmmmeeeerrrrssss((((5555))))
  71.  
  72.  
  73.  
  74.      systems, clock_gettime (CLOCK_SGI_CYCLE) should be used.  This will give
  75.      a timer resolution of 0.8 microseconds.
  76.  
  77.      On Origin3000, Origin300, Onyx3000, Onyx300, and Fuel series systems the
  78.      resolution of the hardware real-time clock can be set with the prom
  79.      command "rtc <kHz>".  The RTC drives the fast clock.  The default kHz is
  80.      1250 and thus has a resolution of 0.8 microseconds.  The value of kHz
  81.      should not be changed by more then an order of magnitude.  Many digital
  82.      media hardware boards expect a 1250 kHz RTC and so changing it will break
  83.      their behavior.
  84.  
  85.      _E_v_e_n_t _t_i_m_i_n_g is typically used by the programmer to measure the elapsed
  86.      time between events.  By examining the time before and after an operation
  87.      and then computing the difference, the application can calculate the
  88.      elapsed time of the operation.  The POSIX clock_gettime(2), the System V
  89.      time(2), times(2) and Berkeley gettimeofday(3B) calls may be used to that
  90.      end.  IRIX also allows the user to map a hardware counter into the user
  91.      address space and read it directly for low overhead time snapshots.
  92.      Information about the address and rate of the hardware counter is
  93.      available through the SGI_QUERY_CYCLECNTR request to the syssgi(2) system
  94.      call.  The mmap(2) system call can then be used to make the counter
  95.      directly available to the user process.
  96.  
  97.      _P_r_o_c_e_s_s _e_x_e_c_u_t_i_o_n _t_i_m_e _a_c_c_o_u_n_t_i_n_g is typically measured under System V
  98.      with the times(2) system call and under Berkeley with the getrusage(3)
  99.      system call.  Traditionally under UNIX, the time reported by these system
  100.      calls is measured by the scheduling clock.  On each clock tick the kernel
  101.      examines the processor status word and charges the running process a
  102.      tick's worth of execution time in user or system mode.  The most
  103.      significant drawback of this scheme is limited precision.  Under IRIX,
  104.      the kernel keeps track of process state transitions between user and
  105.      system modes and accumulates the elapsed time between state transitions.
  106.      This information is available through the times(2) and getrusage(2)
  107.      system calls.
  108.  
  109.      System _t_i_m_e _o_f _d_a_y can be obtained via the _g_e_t_t_i_m_e_o_f_d_a_y(_3_B) system call.
  110.      On the Challenge Series, there is a 64 bit counter that is used to
  111.      maintain system time.  The system initializes a timebase at startup using
  112.      the battery backed time of day clock and associates a counter value with
  113.      that timebase.  Subsequent gettimeofday() calls will return the original
  114.      timebase plus the difference between the current counter value and the
  115.      original startup counter value.  The resolution of this 64 bit counter is
  116.      21 nanoseconds.  A gettimeofday() call causes the kernel to report the
  117.      current time plus the difference between the current counter value and
  118.      the last snapshot value of the counter from the scheduling clock.  On
  119.      some other Silicon Graphics machines, there is a 64 bit data structure
  120.      that is maintained by the clock processor.  On every clock tick, the
  121.      kernel updates that data structure by an amount equal to the clock tick
  122.      (typically 10 milliseconds).  A gettimeofday() call will return the
  123.      current value of that structure.  When timed(1M) is running, the
  124.      gettimeofday() and time(2) results will be adjusted to match time of
  125.      other machines running timed within a local area.
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. ttttiiiimmmmeeeerrrrssss((((5555))))                                                            ttttiiiimmmmeeeerrrrssss((((5555))))
  137.  
  138.  
  139.  
  140.      On Challenge Series machines timers live on the processor where the
  141.      program that created them was running at the time they were created.  A
  142.      timer stays connected to that processor until it expires, is disabled or
  143.      the user restricts or isolates the processor with the timer.  If a user
  144.      restricts or isolates a processor with timers, all of the timers are
  145.      moved to the processor that owns the clock as reported by sysmp(2).
  146.  
  147. SSSSEEEEEEEE AAAALLLLSSSSOOOO
  148.      clock_gettime(), clock_settime(), clock_getres(), getitimer(2), sysmp(2),
  149.      syssgi(2), time(2), timer_create(3C), timer_delete(3C),
  150.      timer_getoverrun(3C), timer_gettime(3C), times(2), getrusage(3),
  151.      gettimeofday(3B)
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.                                                                         PPPPaaaaggggeeee 3333
  196.  
  197.  
  198.  
  199.